fix: move log collector creation logic #1870
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description:
Fixes: #1833
The resource leak was being caused by a state where if a failure occurred while creating an enclave (eg. ctrl+C while running
kurtosis enclave add
) at a point where the log collector container was created BEFORE it had been connected to the network AND before the necessarydefer undo
s to clean up the log collector had been queued THEN the network would get cleaned up by thedefer undo
fromCreateNetwork
, but the log collector container would remain.Any attempt to do a
kurtosis clean -a
would fail to clean log collector container because the network(and thus enclave) the container was created for had already been cleaned up.After digging - I realized the log collector was being created in
container-engine-lib
as opposed to in theengine
Moving the logic to the engine AFTER the enclave is created fixes the issue. If there is an error at ANY point in the creation of the log collector container (even if the log collectorsdefer undo
hasn't been queued), thedefer undo
from theCreateEnclave
call will clean the log collector because it has a label with theenclaveUUID
.Is this change user facing?
NO
References:
#1833